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Abstract 

Cloud computing relies on secure and efficient virtu¬ 
alization. Software level security solutions compro¬ 
mise the performance of virtual machines (VMs), as a 
large amount of computational power would be uti¬ 
lized for running the security modules. Moreover, 
software solutions are only as secure as the level that 
they work on. For example a security module on a 
hypervisor cannot provide security in the presence of 
an infected hypervisor. It is a challenge for virtualiza¬ 
tion technology architects to enhance the security of 
VMs without degrading their performance. Currently 
available server machines are not fully equipped to 
support a secure VM environment without compro¬ 
mising on performance. A few hardware modifications 
have been introduced by manufactures like Intel and 
AMD to provide a secure VM environment with low 
performance degradation. In this paper we propose 
a novel memory architecture model named Architec¬ 
tural Support for Memory Isolation(ASMI), that can 
achieve a true isolated physical memory region to each 
VM without degrading performance. Along with true 
memory isolation, ASMI is designed to provide lower 
memory access times, better utilization of available 
memory, support for DMA isolation and support for 
platform independence for users of VMs. 

1 Introduction 

In a server system, sharing resources among virtual 
machines (VMs) implies that the resources of the 
server are accessed simultaneously among different 
users. Users’ concerns about physical device sharing, 
stem from the fact that their data resides in these 
shared devices, and virtualization technology has to 
provide the necessary mechanisms to ensure the secu¬ 
rity of user data. Protection of user data at differ¬ 
ent levels of architecture like CPU, memory and In¬ 
put/Output (I/O) devices has to be provided, proved 
and assured to convince the users of the credibility 


of the system. The survey reports mm® on the 
security of VMs, show that 

• VMs should be as isolated as physical machines, 
i.e., the only means of communication between 
them should be exactly as between two different 
physical machines (Isolation Property of VMs) 

• Hypervisors cannot be trusted, due to the pos¬ 
sibility of hypervisor based malware, and other 
infections possible on hypervisors 

An isolated VM environment can be provided by the 
hypervisor, either through hardware modifications or 
through additional software modules that restrain a 
VM from accessing other VMs’ data at various archi¬ 
tectural levels [I]. Software modules to impose these 
restrictions would take additional CPU clock cycles 
and thereby reduce VM performance, implying that 
software solutions could provide security to VMs only 
at the cost of compromising VM performance. A 
hardware modification could impose these restraints 
with a lesser performance degradation, as it would use 
either a marginal number of additional clock cycles, 
or simply a negligible increase in the pipeline cycle 
time. Hence, we aim at designing enhancements to 
hardware that can achieve security for VMs without 
compromising on their performance, and also provide 
security in the presence of compromised hypervisors. 

This paper reviews literature in the area of mem¬ 
ory virtualization to identify open challenges that 
prevent hypervisors from providing a true isolated 
environment for VMs without losing out on perfor¬ 
mance. Some open challenges have been identified and 
a memory architecture model aimed at solving those 
challenges is proposed, which unlike existing mem¬ 
ory models like nested paging and IOMMU, does not 
degrade performance. ASMI (Architectural Support 
for Memory Isolation), our proposed model, requires 
modification to hardware and is illustrated with the 
help of hardware currently in popular use for support¬ 
ing VMs. 
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Memory virtualization techniques used in present 
day systems have been reviewed in the Section [2j 
along with the open challenges in memory virtualiza¬ 
tion. Necessary features in any technology designed 
for improving VMs in terms of security and perfor¬ 
mance are identified in Section [3j along with a de¬ 
scription of the design of ASMI. Section [4] concludes 
the article with future directions of research. 

2 Memory Virtualization 

The normal paging mechanism cannot be used [3] in 
a virtualized environment. In a normal computing 
environment, the paging hardware is accessed by the 
single operating system to get the physical address 
corresponding to the virtual address. In a virtual en¬ 
vironment, a single physical memory is shared among 
different VMs or guest operating systems (hereafter 
referred as guest OS, in this paper). 

If a guest OS accesses the paging hardware to trans¬ 
late its virtual address, there are possibilities that a 
guest OS may access a physical address which is pre¬ 
viously accessed by another guest OS. As this is a se¬ 
rious security threat to the isolation property of VMs, 
the security of VMs at memory level, has to be assured 
by isolating the physical pages of each VM from oth¬ 
ers. A mechanism to differentiate the physical address 
of each guest OS is a mandatory requirement. 

A memory virtualization mechanism that is popu¬ 
larly used in VM technology nowadays to achieve dif¬ 
ferentiation of logical addresses is called Nested Pag¬ 
ing EP- The following section describes nested paging. 

2.1 Nested Paging 

In nested paging j3] , the virtual address of the process 
running in each VM is converted to a pseudo physical 
address by the corresponding guest OS. This trans¬ 
lation is achieved by looking up page tables, which 
are maintained by the guest OS [3|. In the next level 
of translation, the pseudo physical address stored in 
page tables of each guest OS is translated to the ac¬ 
tual physical address by the hypervisor. This trans¬ 
lation is stored in the real map table maintained by 
the hypervisor [4j. The hypervisor maintains a sep¬ 
arate real map table for each guest OS. These two 
page tables, in combination, are known as a nested 
page table. Thus, in a virtual environment, there are 
three layers of memory j4|. They are Physical Mem¬ 
ory (Original device memory, visible to hypervisor), 
Pseudo Physical Memory (Virtual view of physical 
memory to VMs, visible to guest OS) and Virtual 
Memory (Logical memory for each program, visible 
to process) 

On contemporary platforms, page translation is 
supported by a combination of page table and a trans¬ 
lation lookaside buffer (TLB). Currently there are two 
different types of hardware configurations available for 
address translation. One is an architectured page ta¬ 


ble. The second is an architectured TLB [3]. Vir¬ 
tualizing these hardware configurations is a primary 
requirement for memory virtualization. 

Each guest OS maintains its own page tables. These 
page tables represent the virtual to pseudo physical 
mapping that guest OS manages. To virtualize the 
architectured page table, a shadow page table [4] is 
used by the hypervisor, which contains the virtual ad¬ 
dress and the corresponding physical address. Each 
VM should have a shadow page table. When a con¬ 
text switch (among VMs) occurs, the shadow page 
table in use by the hypervisor changes according to 
the currently active VM [4]. Shadow page tables are 
updated along with the nested page tables. 

In an architectured TLB, TLB stores the recently 
occurred virtual to physical address translations. But 
in a virtual environment these entries will be differ¬ 
ent for each guest OS. So, when the context switch 
between VMs happens, the TLB has to be flushed to 
avoid the guest OS accessing the translations of an¬ 
other guest OS. TLB flush on each context switch is 
computationally expensive A 5j. Moreover, failure 
to hit the TLB causes many extra pipeline cycles. 

To overcome the problem, designers added an ex¬ 
tra field named Address Space Identifier (ASID) to 
the TLB. The ASID held is used to distinguish the 
address of currently running process in a normal en¬ 
vironment |4j. The ASID held entry shows the owner 
(process) of the address translation entry in the TLB. 
In a virtualized system, a virtual TLB is maintained 
by the hypervisor, which contains the virtual ASID 
held, virtual page held and the real page held. An 
ASID map table is maintained by the hypervisor to 
map the virtual ASID, of each process in each VM, 
to a unique real ASID value. Only the address trans¬ 
lations of the currently running process in the active 
guest OS, are allowed to access from the TLB (distin¬ 
guished by the real ASID held) [4j. 

Nested page tables along with either virtualized 
versions of architectured page tables or with virtu¬ 
alized versions of architectured TLBs, create a vir¬ 
tual address space in VMs. However, there are issues 
with this addressing mechanism, from the perspec¬ 
tive of performance and security. The nested paging 
technique compromises security while enabling Direct 
Memory Access (DMA) mechanism |3| [6j . 

The DMA mechanism is designed to work with the 
actual physical address space. If the DMA mechanism 
is enabled, the guest OS can reconfigure the device 
to access the memory of another VM through DMA 
mechanism [7]. A solution to this security threat, is to 
disable the DMA mechanism. Disabling DMA reduces 
performance because more CPU clock cycles would 
be required for data transfer between memory and 
I/O devices. Protecting memory by access from other 
VMs while enabling DMA mechanism in I/O devices, 
is called DMA isolation. DMA isolation has to be 
achieved to enable the DMA mechanism and thereby 
improve the performance of VMs. 

The requirements for better performance without 
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compromising security led to the development of 
another address translation mechanism named I/O 
Memory Management Unit (IOMMU) [81 which is ex¬ 
plained next. 

2.2 IOMMU 

The IOMMU architecture is illustrated here with the 
help of an Intel based technology named Intel VT-d 
[9]. Intel introduced a DMA remapping hardware in 
their chip set. A generalized IOMMU architecture is 
implemented inside this DMA remapping hardware. 
The process of converting the DMA address from one 
form to another (virtual address to physical address) 
is known as DMA remapping. The hardware for DMA 
remapping is called DMA remapping hardware. 

Intel VT-d architecture divides the physical address 
space into different partitions. Each partition is a sub¬ 
set of the entire physical memory. Each partition is 
considered as a protection domain [9] [6j. I/O devices 
are allocated to a single protection domain by the hy¬ 
pervisor. I/O devices are not allowed to access any 
domain other than the one it is allocated. VMs are 
also allocated to a protection domain by the hypervi¬ 
sor. A VM is allowed to access only the I/O devices 
that are allocated to its own domain. VT-d enables 
hypervisor to allocate one or more I/O devices to a 
protection domain. 

DMA isolation is achieved by restricting the access 
to a protection domain by the I/O devices not as¬ 
signed to that domain. DMA isolation is implemented 
through two address translation tables used in this ar¬ 
chitecture 0 0. They are 

• Root Entry Table (RET) 

• Context Entry Table (CET) 

VT-d hardware treats the address in a DMA request 
as a DMA Virtual Address(DVA) [9] 0. DVA can be 
a guest physical address (pseudo physical address) of 
the VM to which the I/O device is assigned. Thus, 
I/O devices that are assigned to a protection domain 
can be provided a view of memory that is different 
from the host physical memory. VT-d transforms the 
DVA address to the host physical address with the 
help of RET and CET. 

Each DMA address has three fields 0 0. They 
are Bus number , Device number and Function num¬ 
ber. The bus number field content is used to index into 
the RET. Each entry in the RET point to a CET. The 
device number and function number field contents are 
collectively used to index into the CET. Each entry in 
CET points to an address translation structure which 
is a multilevel page table similar to a IA-32 proces¬ 
sor page table named hierarchical translation struc¬ 
ture 0. 

Since VMs are in different protection domains, I/O 
devices alloted to a VMs protection domain would not 
be able to access the memory of another VM. Thus, 
in VT-d architecture, the DMA mechanism can be 


enabled without compromising the security, thereby 
improving the performance of I/O devices, and con¬ 
sequently the performance of VMs. 

It is observed from the two memory management 
techniques, nested paging and IOMMU, that nested 
paging would have the worse performance of the two, 
due to the inability to safely use DMA. IOMMU ar¬ 
chitecture allows the use of DMA and could achieve 
DMA isolation, as the I/O devices and VMs are per¬ 
mitted to access only one protection domain. Memory 
translation is a two level lookup and is hence slower 
than a normal environment. 

Though the IOMMU architecture provides better 
DMA isolation than nested paging, it still stays vul¬ 
nerable to many security threats. In order to illustrate 
the problem, we discuss the security threats and pro¬ 
posed solution in literature, in the succeeding para¬ 
graphs. 

2.3 Security Threats 

A survey on the security of VMs shows that there ex¬ 
ist vulnerabilities at different architecture levels like 
CPU, memory and network, which would help a ma¬ 
licious VM to easily gain the control of the hypervisor 
[lj. In the IOMMU architecture, the hypervisor has 
access to all the memory locations including the en¬ 
tire allocated memory space for machines. This would 
result in the situation that a malicious VM infects a 
hypervisor or an infected hypervisor could attack or 
access the memory of another VM. Providing security 
in the presence of infected hypervisor is considered 
an open research problem in the area of the security 
of VMs [7 . For improved security in the context of 
infected hypervisors, solutions that move the protec¬ 
tion of memory from hypervisor level to the hardware 
level are desirable [7]. The proposed work in [7 , called 
HyperWall, is briefly discussed. 

2.3.1 HyperWall 

HyperWall [7] is an architectural solution aimed at 
providing hardware for protecting guest VMs from a 
malicious hypervisors. The HyperWall hardware is 
proposed as an extension to the IOMMU hardware 
unit. The authors claim that the key feature of Hy¬ 
perWall is Confidentiality and Integrity protection 
to VMs. HyperWall architecture provides additional 
protection bits to each memory page without modi¬ 
fying the paging structure in the hypervisor or guest 
OS. Four protection bits are used by HyperWall asso¬ 
ciated with each physical page. These protection bits 
can represent four new protection modes to the phys¬ 
ical page. They are Not assigned to any VM (Hyper¬ 
visor access only), Assigned to a VM with hypervisor 
and DMA allowed , Assigned to a VM with hypervisor 
access denied and Assigned to a VM with neither hy¬ 
pervisor nor DMA allowed. The pages assigned to a 
VM are protected from other VMs and the hypervisor 
by applying these user specification protection modes 
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to each page. 

According to our analysis, there exist security issues 
with this architectural solution. They are 

• HyperWall architecture aims to protect only the 
confidentiality and integrity of a VMs data and 
not availability. However, availability is also an 
important security property. The architecture 
does not provide the assurance of a minimum and 
fair amount of memory to all VMs at all point of 
their active lifetime. It allows the VM user to set 
the memory page with a protection level which 
denies access to DMA and hypervisor. Hence, 
any malicious VM can use this feature to create 
memory starvation for other VMs by locking sev¬ 
eral pages at a time. 

• HyperWall does not protect against covert chan¬ 
nels and side channels attacks [7],which are the 
main threat towards the isolation property of 
VMs pp. Most of the covert channel attacks 
are done through memory uni, in m na. 
Without preventing those attacks at the memory 
level, true isolation in the memory level cannot 
be achieved. 

Apart from security threats, there are performance 
challenges to be met by virtualization mechanisms. 
In the next two paragraphs, we state the major 
reasons for memory slowdown that result in under¬ 
performance, as identified in our survey. 

2.4 Underutilization of Memory 

Our survey on the challenges in memory architecture 
shows that a huge volume of unutilized memory is 
allocated to VMs El E3- It is because, in the current 
VM environment, the requested physical memory is 
divided and allocated to VMs when they are created. 
That memory would not be used by the assigned VMs 
if they do not need that memory. But, it cannot be 
assigned to other VMs that require memory. A fairer 
allocation of physical memory is required. 

Ginseng [14] is a solution to the problem of under¬ 
utilization of VM memory. Ginseng runs in the hy¬ 
pervisor, and allocates physical memory to a guest OS 
via a balloon driver. The balloon driver is installed in 
each guest OS. A balloon controller is installed in hy¬ 
pervisor. The communication between balloon driver 
in guest OS and balloon controller in hypervisor is 
done through libvirt HU: an application programming 
interface (API) for managing the hypervisor. 

There are two types of communication modes be¬ 
tween the balloon driver and balloon controller, In¬ 
flation and Deflation. In inflation, the balloon driver 
transfers memory from guest OS to the hypervisor. 
The hypervisor keeps such memory from each guest 
together as a memory pool, available to guest OS 
when its assigned memory is over-utilized, through 
deflation. By inflation and deflation, Ginseng solves 
the problem of memory starvation effectively. 


Mortar El is another technique which helps to uti¬ 
lize this underutilized memory as a cache. There are 
two uses for this cache. The first one is to use it as 
a cache for pre-fetching disk blocks. The next is to 
use it as a an application level distributed cache that 
follows the memcached m protocol. Rather than al¬ 
locating the underutilized memory to guest OS, this 
architecture pools together the spare memory on each 
guest OS and exposes it as a volatile cache. When¬ 
ever the guest OS require its memory, the memory 
cache objects are freed and given back to the guest 
OS. This architecture also efficiently uses the under¬ 
utilized memory. 

The main difference between Ginseng and Mortar is 
that Ginseng pools the unallocated memory and gives 
it to other VMs, while Mortar pools the unallocated 
memory and uses it as an application level cache. 

Our analysis is that both Ginseng and Mortar are 
susceptible to covert channel based attacks by col¬ 
luding VMs on the same server, thereby risking user 
program and data on the VMs. 

2.5 Memory Access Times 

Another major challenge in VM technology is to im¬ 
prove the access time of memory for processes. Both 
nested paging technique and IOMMU architecture use 
two level memory address translation. In nested pag¬ 
ing architecture as well as in IOMMU architecture, 
address translation hardware is virtualized in such a 
way that the address translation hardware is directly 
accessible to hypervisor and not to guest OS 0 0- 
HyperWall architecture does not offer any improve¬ 
ment in VM performance over IOMMU or nested pag¬ 
ing either. 

Existing literature also includes illustrations of 
challenges and solutions in deduplication m ei and 
double-paging m features of VMs. Deduplication 
and double-paging are implemented in hypervisors, 
by sharing the memory pages among VMs and hy¬ 
pervisor. Those features are considered as a threat to 
memory isolation [T|, and are hence not advisable for 
use in clouds. 

Enabling the access of address translation hardware 
directly by the guest OS removes one level of indirec¬ 
tion in address translation process. This would im¬ 
prove the performance of VMs by improving the aver¬ 
age memory access time. Clearly the need of the day 
is to have a memory virtualization infrastructure that 
supports the following properties even in the presence 
of a malicious hypervisors. 

• Isolated physical memory region to each VM 

• Guest OS should be able to use the address trans¬ 
lation hardware directly 

• Fair allocation of physical memory among VMs 
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3 Architectural Support for 
Memory Isolation 

The analysis presented in the previous section clearly 
establishes that a novel mechanism has to be intro¬ 
duced, such that it would be able to protect the mem¬ 
ory of a VM from a malicious hypervisor, address the 
problem of underutilization of memory in VMs, and 
allow the user programs to use the address translation 
hardware directly, for improved VM performance. We 
propose ASMI, Architectural Support for Memory Iso¬ 
lation , that can satisfy the above requirements. Fig¬ 
ure [l] illustrates the proposed architecture. 

We propose ASMI as a generic solution, aimed at 
providing hardware for enabling direct access to phys¬ 
ical memory by the VMs. We illustrate and expand 
the concept on an Intel platform with Intel-VT capa¬ 
bilities |H] , as details about the existing technology are 
available in literature. Hence, hereafter, in this paper, 
ASMI refers to the design enhancement we describe 
in the succeeding paragraphs. 

Description In an Intel 64 bit architecture, the 
address translation mechanism disables segmentation 
and only paging mechanism exists [20]. In ASMI, seg¬ 
mentation is enabled and utilized to improve isolation. 
The physical memory is partitioned into physical seg¬ 
ments. Each segment should be of a fixed length. 
Each segment contain fixed number of pages. A new 
hardware unit named Pro-mem controls the entire 
physical memory. 

A new register named VMIDR is introduced and its 
contents managed by each processor to store the iden¬ 
tity of the currently running VM on that processor. 
A unique ID is assigned and stored in VMIDR regis¬ 
ter by the Pro-mem unit when a new VM is created. 
Switch between VMs on a processor causes a changes 
in the VMIDR value, done by the Pro-mem. Moving 
the control of execution from VM to hypervisor and 
vice versa would be informed to the Pro-mem by the 
VM Exit and VM Entry instructions. 

VM Entry and VM Exit are the instructions in Intel 
VT architecture [5] that move the execution to and 
fro between VMs and hypervisor. In the proposed 
architecture, these instructions are modified to inform 
the Pro-mem unit about the control transfer among 
VMs and hypervisor in an atomic manner. 

SegMax is introduced, which is maintained by Pro- 
mem and contains the maximum number of seg- 
ments(MSEG) that can be assigned to a VM when 
the entire physical memory is full. The value stored 
in MSEG is calculated by dividing the total number of 
physical segments (TSEG) in primary memory with 
TOT, where TOT is the sum of total number of VMs 
and hypervisor running above the hardware. 

SegMax, MSEG, and TOT values are not fixed. 
They are changed when a new VM is created or when 
an old one is destroyed. TSEG is fixed at boot time, 
by the hypervisor, depending on the page size that 


the hypervisor is designed to work with. TSEG val¬ 
ues cannot be changed until next reboot. Initially at 
boot time, MSEG and TOT values are zero. When a 
hypervisor is loaded or a VM is created, TOT value 
is incremented by one and MSEG is recalculated ac¬ 
cording to the new TOT value. 

A new data structure named Memory Protection 
Table (MPT) is also proposed, and it is managed by 
the Pro-mem. MPT contains the segment ID (SegID) 
and its corresponding virtual Machine ID (VMID). 
Each segment can be assigned to a single VM. MPT 
would be stored in the primary memory as shown in 
Figure ]T| This primary memory portion of MPT will 
be inaccessible to any software module. This table is 
accessible only to the Pro-mem unit. A VMID value 
zero in MPT is used to indicate the segments that 
belongs to the hypervisor. 

Initially, when the physical machine boots, the 
MPT will be empty. When the hypervisor is started 
by the BIOS, Pro-mem stores a unique ID to the 
VMIDR register. Similarly when a VM is created, a 
unique ID is stored in VMIDR register by Pro-mem. 

When the VM exit instruction is executed, VMIDR 
contents would get stored in the initial address of the 
first memory segment of the corresponding VM and 
the VMIDR is loaded with the initial address of the 
first memory segment of the hypervisor. Similarly 
when the VM entry instruction executes, the VMIDR 
value is stored in the initial address of the first seg¬ 
ment of hypervisor and the VMIDR value is loaded 
from the initial address of the first segment of the 
running VM. These load and store operations are ex¬ 
ecuted by Pro-mem as atomic operations to VM exit 
and VM entry instructions. 

Allocation When a VM requests for a memory 
page, Pro-mem would check for available free pages 
in the allotted segments. If a free page is available in 
the allotted segment, it would be assigned to the VM. 
If no free pages are available, Pro-mem would check 
for a free segment. If a free segment available, it is 
allotted to the current VM, the MPT updated and 
the page assigned to the VM. 

When no free segments are available, Pro-mem 
would check whether any of the VMs has been allot¬ 
ted more than MSEG number of segments. The num¬ 
ber of segments by which it exceeds MSEG would be 
informed to the corresponding VM by the Pro-mem, 
to make it free through swapping. Then those pages 
would free be used by the requesting VM. If no VM 
is using more than MSEG segments, Pro-mem will 
send a memory full exception to the requesting VM. 
This exception can be used by the guest OS to swap 
its allotted memory pages and load the new one, and 
thereby continue its execution. 

The above techniques ensure a minimum number 
of physical segments or a minimum amount of phys¬ 
ical memory to each VM when the physical memory 
need is the maximum. It simultaneously ensures that 
physical memory is not be left free or unutilized when 
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Figure 1: ASMI: Architectural Support for Memory Isolation 


a VM requires it. Hence, an optimum utilization of 
physical memory can be achieved by this architecture. 

Access Access to segments would be validated by 
Pro-mem with the help of VMIDR value and MPT 
table. Pro-mem would raise an exception if a VM 
or hypervisor tries to access the segment which is not 
allotted to it. The main advantage of this architecture 
is that it can provide memory isolation among VMs 
and hypervisor irrespective of the hypervisor security. 

In this version, we propose Pro-mem to be installed 
in between hardware paging architecture and primary 
memory. The paging unit would be modified to in¬ 
clude Pro-mem functionality. Each guest OS main¬ 
tains a page table in memory, which contains the vir¬ 
tual address and its corresponding physical address. 
The guest OS gives the virtual/linear address to the 
paging unit. The paging unit would give this linear 
address to the Pro-mem unit. Pro-mem would return 
the physical address, within the guest OS alloted seg¬ 
ment, to the paging unit. The paging unit would re¬ 
turn this physical address to the guest OS. 

Performance and Security The physical address 
obtained in guest OS, by the address translation de¬ 
scribed above, would be the actual physical address 
within the allotted physical segment. Only a single 
level address translation is required in this architec¬ 
ture. It would improve the performance of VMs, as 
it improves over two level translation. DMA can be 
enabled because the memory allotted to a VM can not 
be accessed by the other VMs as they are separated 
by different segments. Separating the physical mem¬ 
ory of each VMs at the hardware level could provide 
hypervisor-independent security to VMs. 

Operating systems in a normal environment use the 
paging hardware to translate linear addresses to phys¬ 
ical addresses. In a virtual environment, the guest 
operating system uses the paging hardware with Pro¬ 
mem to translate its linear address to the physical 
address, and the physical address range is controlled 


by the Pro-mem. Thus, the guest operating system 
directly uses the address translation hardware (Pag¬ 
ing unit with Pro-mem) similar to the normal (not 
virtualized) environment. Hence, no modification to 
guest OS is required. This enables the use of native 
operating systems, and a performance much better 
than existing virtualized systems. 


4 Conclusions and Future Work 

A memory architecture model named ASMI, has been 
proposed and described in the paper. ASMI provides 
an isolated memory region to each VM and the hyper¬ 
visor. ASMI has been illustrated in this paper on an 
Intel Platform with hardware enhancements to imple¬ 
ment the design. ASMI is designed to provide mem¬ 
ory isolation to VMs, irrespective of the integrity of 
hypervisor. 

Our architecture includes an address translation 
unit named Pro-mem. Pro-mem is shared among VMs 
in time division multiplexing without compromising 
security, to improve address translation performance. 
The design of Pro-mem solves the problem of under¬ 
utilization of memory, as Pro-mem allocates memory 
to VMs only on individual requests and does not pre¬ 
allocate. ASMI can thus provide confidentiality, in¬ 
tegrity and availability to VMs at memory level irre¬ 
spective of hypervisor security without compromising 
performance. 

Implementing ASMI through kernel level simula¬ 
tions and comparison of the security and performance 
of VMs with the currently available memory archi¬ 
tectures like IOMMU and nested paging are planned 
as future tasks in our research. ASMI is a generic 
solution. Studying the suitability of ASMI on other 
architectures like MIPS, and other RISC variants, is 
also included in our research agenda. 
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